The Internet has had a profound affect on various aspects of everyday commerce. More and more individuals are utilizing the Internet to electronically perform tasks which were previously performed in other ways. For example, electronic transactions are now commonplace on the Internet. Such transactions include electronic banking, electronic bill presentment, electronic bill payment and electronic purchasing.
As the use of the Internet for electronic commerce has developed, a model has emerged in which users often access other entities on the Internet through a trusted entity such as a financial institute. These entities through which access to other entities is made will hereinafter be referred to as “portals”.
The portals are often supported by a service provider. The service provider, for example, may process electronic user requests, which are received by the portal, for information relating to a user's deposit account at a particular bank by electronically accessing information maintained by the applicable bank and processing that information so that it can be presented to the requesting user in a user friendly form.
Similarly, the service provider may also be the entity which responds to user requests received by the portal for billing information. For example, the service provider may receive summary bill information from numerous billers for numerous users and process this information such that the appropriate information can be presented in a user friendly manner in response to a request for bill information submitted by the user to the portal. However, if the user desires more detailed billing information, it is often preferable for the detailed bill information to be provided to the requesting user directly by the biller rather than by the service provider through the access portal.
Security of network communications relates to various aspects of protection. These include (i) secrecy, i.e. can someone other than the intended party view the data in transit?, (ii) immutability, i.e. how can one be assured that someone has not altered the data in transit?, (iii) authentication, i.e. how can one ensure that each party in the conversation, e.g. session, is who it says it is?, (iv) authorization, i.e. is the authenticated party allowed to do what it is requesting to do?, and (v) non-repudiation, i.e. can a party repudiate its involvement, e.g. its actions?.
Secrecy is generally provided by encrypting data. For example, encrypted HTML, i.e. HTML/HTTPS (SSL), is used to insure that unintended parties can not see the information as it travels across the network, e.g. the Internet. However, this does not prevent the various transit points, e.g. the service provider and the portal, from viewing data that travels over the network. Thus, for example, a URL to a payor's detailed bill information could be misappropriated at a transit point or from the payor's terminal, e.g. from the payor's browser history, and could then later be used to access the payor's detailed bill information.
Like secrecy, immutability is also generally provided by encrypting the data. Typically, due to the nature of the algorithms, encryption which provides good secrecy also provides good immutability. For example, HTML/HTTPS is used to insure immutability as the data bits are travelling across the network. That is, even if one were to improperly access data off a network router, or at a transit point, it would be virtually impossible to read the misappropriated data; however, the data still could be altered. Thus, for example, an account number associated with the payor's detailed bill information could be misappropriated at a transit point and mangled. It this were to occur, the biller would have no way of confirming that a payor account number, originally sent by the portal to the payor and then sent by the payor to the biller with the request for detailed bill information, has not been misappropriated and mangled before being received by the biller.
FIG. 1 is a somewhat simplified network diagram indicating various channels which may be established between network entities to provide electronic bill presentment services. As shown in FIG. 1, the network includes users A–C which are represented on a network by network devices 105A–105C. The network devices 105A–105C could, for example be any device capable of communicating over the network, such as a personal computer, palm computer, set top box etc. Billers A–C are also represented on the network by network devices 110A–110C, typically although not necessarily high power workstations, mini-computers or mainframe computers, often referred to as servers. The network also includes an access portal 115 and a service provider 120.
Users A–C access services available on the network by establishing channels 125A–125C with the access portal 115. The access portal is linked to the service provider 120 by channel 130. The service provider in turn is linked to the billers A–C by channels 135A–135C.
For example, the channels 125A–125C may be Internet channels which are established through an Internet access provider, such as America Online (not shown), using a browser, such as browsers currently available from Microsoft Corporation and Netscape Corporation. Accordingly, the communications between the user devices 105A–105C and the access portal 115 are typically encrypted HTML communication, i.e. HTML/HTTPS.
Communications between the access portal 115 and the service provider 120 typically will follow a protocol such as IFX, or OFX etc., which may better ensure the security of the communications whether the link is via a private network or a public network such as the Internet. Similarly, communications between the service provider 120 and the biller network devices 110A–110C will also typically follow an established protocol and be transmitted via channels 135A–135C which are provided on a private or public network.
If detailed bill information is desired by a user, further communications channels must be established between the requesting user and the appropriate biller. Accordingly, if user A desires detailed billing information relating to the bills of billers A–C communication links 140A–140C will be required as shown in FIG. 1. These communication links will typically be established via the Internet using an Internet browser and accordingly carry encrypted HTML communications. It will be recognized that channels similar to channels 140A–140C could be established between user devices 105B and 105C and biller devices 110A–110C to communicate detailed bill information from billers A–C to users B and C.
Each of the users A–C will typically be known to different network entities by different identifiers. For example, as shown in FIG. 2, each of the users A–C are known to each of the billers A–C by the user's name, e.g. A, B or C, the applicable user's address, e.g. ZA, ZB or ZC, and a unique account number, e.g. AA–CC which each biller associates with each user.
The access portal 115 will typically know each of the users A–C by a unique user name, e.g. A′–C′ and a unique password, e.g. PA–PC. Alternatively, users may be known to the access portal 115 by a digital certificate, e.g. a digital signature, although this is relatively uncommon today.
The user name and password or digital certificate are often referred to as the user's credentials and are used by the access portal 115 to authenticate the user. The access portal 115 then vouches for authenticated users to other network entities. Should a particular user also have a transactional relationship with the access portal, for example if the access portal is a user's financial institute or stock brokerage firm, the user will also typically be known to the access portal by additional information similar to that shown in the biller columns of FIG. 2.
FIG. 3A depicts typical communications between and functions of various network entities in providing bill summary information to a requesting user. As shown, network device 105A, representing user A, implements a browser 305, typically stored on a local memory, to communicate its credentials via an encrypted HTML communication over the Internet channel 125A to the access portal 115. The access portal 115 processes the credentials to authenticate user A, as indicated by reference numeral 310. Portal 115 then provides a response, as represented by the communicated authentication message, to network device 105A either granting or denying access based on whether or not user A has been successfully authenticated by the processing of the credentials. If access is granted, user A, operating network device 105A, may now request bill summary information from the access portal 115 via the channel 125A.
Having authenticated user A, the access portal 115 transmits the request for bill summary information via a protocol over channel 130 to the service provider 120. In response to the request, the service provider 120 retrieves the bill summary information and applicable universal resource locators (URL's) 315 from, for example, a local memory. The bill summary information and URL's 315 are typically provided by the billers via protocol or batch transmissions over channels 135A–135C to the server 120 off-line, i.e. in non-real time, with respect to the user request for the bill summary information.
The bill summary information and URL's are provided over channel 130 from the service provider 120 to the access portal 115. The access portal 115 then directs the bill summary and associated URL's to the user Internet device 105A via the Internet channel 125A in an encrypted HTML message.
Accordingly, bill summary information and URL's flow via a protocol from the biller to the service provider and from the service provider to the access portal. The bill summary information is only provided by the access portal to the user after authentication of the user. Further, the bill summary information and associated URL's for a particular user are provided to the access portal for transmission to the requesting user only if the access portal can vouch for the user to the service provider based upon its authentication of the user.
The URL's associated with the bill summary information represent the addresses to the bill detail information stored on the network 100 for the transmitted summarized bill information. The bill detail information of billers A–C may be respectively stored, for example, on the memories 320A–320C. It should be recognized that, as described in the above-referenced related applications, the bill detail information could also or alternatively be stored at the service provider 120 or at another network site controlled, for example, by a bill aggregator. In any event, the URL's to the bill detail information are passed, along with the bill summary information, from the service provider 120 to the access portal 115 and from there to the user network device 105A. Typically each URL is embedded as a hyperlink in the applicable bill summary information presentation which will appear on a display included in the network device 105A.
A typical display is shown in FIG. 4. FIG. 4 depicts a display 400 of network device 105A which is used to present the requested bill summary information for user A. As shown, the presentation includes the names of billers A–C in display areas 405A–405C, the applicable bill amounts XA–XC billed by each of the billers A–C to user A in display areas 410A–410C, and a view bill request area associated with each of the billers A–C in display areas 415A–415C which can be clicked on using a mouse or other input device to activate the applicable hyperlink URL HA-HC, identified with reference numerals 420A–420C, to establish a link to the bill detail information underlying the bill summary information being presented. The applicable bill may also be paid directly from the bill summary presentation by clicking on the appropriate pay bill area 425A–425C.
As shown in FIG. 3B, by clicking on view bill area 415A and thereby activating the URL HA identified with reference numeral 420A in FIG. 4, the user network device 105A is linked via an encrypted HTML Internet channel 140A to the biller address, i.e. URL address HA, at which the detailed bill information of the biller A for user A is stored. The detailed bill information is then provided via the channel 140A to the user A network device 105A without either the request or the provided detailed bill information flowing through the service provider 120 or access portal 115.
It should be understood that, if the bill detail information were stored at the service provider 120 or an aggregator (not shown), the hyperlink would link directly to an address at the aggregator or service provider network site at which the requested detailed bill information is maintained. In any event, the access portal 115 does not vouch for user A to biller A, the aggregator, or the service provider 120 in connection with the bill detail request and the bill detail information is communicated to the user A from biller A, the aggregator or the service provider 120 without flowing through the access portal 115.
This lack of authentication by the access portal 115 in connection with the bill detail request from user A is sometimes referred to as “the problem of transitive authentication”. To address this problem it has been proposed to implement an OFX protocol (i.e. Open Financial Exchange Specification 1.51 dated Nov. 23, 1995, www.OFX.net) such that the creator of the bill detail information, e.g. the biller, aggregator or service provider etc., create a somewhat extended URL.
As shown in FIG. 5A, in the proposed implementation of OFX 1.51, the somewhat extended URL 500 includes a network address 505 for the bill detail information, a bill identification (ID) 510 which identifies the particular bill being requested, and a user account number 515 which the biller associates with the applicable user. As indicated in FIG. 5A, the bill ID and user account number are typically encrypted, but may instead be hashed.
FIG. 5B presents a more realistic depiction of the somewhat extended URL 500 of FIG. 5A for a typical Internet address prior to encrypting or hashing the bill ID 510 and user account number 515. More particularly, FIG. 5B depicts the somewhat extended URL 500′ with the network address 505′, the bill ID 510′ and the account number 515′.
The somewhat extended URL 500′ provides the recipient of the request for detailed bill information, e.g. the biller, bill aggregator or service provider, with sufficient information to identify the particular bill based on the bill ID 510′ and to verify the user account number based on account number 515′, prior to allowing access to the detailed bill information stored at address 505′. However, the recipient has no way of verifying that the request has actually been made by the appropriate user, for example user A as shown in FIG. 3B. Furthermore, there is no way for the recipient to know whether the somewhat extended URL originally transmitted by the access portal 115 has been tampered with and, for example, includes modified e.g. mangled, address, bill ID and/or user account number information.
For example, it is impossible for the recipient to know if the somewhat extended URL has been improperly copied from the user's browser either by operation of the user's network device on which the somewhat extended URL may be stored, by hacking into the information stored on the user's network device by the browser, or by installing coding, such as a JAVA applet, which automatically transmits information stored on the user's network device without user's knowledge to a network device under the control of others. It is also impossible for the recipient to know if the encrypted data has been altered. Hence, the proposed implementation of OFX 1.51 cannot ensure the integrity of the somewhat extended URL or serve as an aid in authenticating to the recipient that the requester is who he/she says he/she is.
Accordingly, a need remains for a technique to address the problem of transitive authentication.